Network Functions Virtualization (NFV) aims to consolidate many network equipment types onto industry-standard high-volume servers, switches, and storage devices by using a virtualization technology in the evolving Information Technology (IT) field, thereby changing a manner in which a network operator builds and operates a network and a network service (NS). The NFV implements a network function by using software that can run on a series of industry-standard server hardware, thereby changing a network infrastructure. Moreover, because the software can move dynamically or be instantiated in different network locations according to a requirement without installing a new device, a network operation is further changed.
Referring to FIG. 1, FIG. 1 is a schematic diagram of a system architecture of an NFV system 100 that can be applied in embodiments of the present invention. The NFV system may be implemented by using multiple types of networks, such as a data center network, a service provider network, or a Local Area Network (LAN). As shown in FIG. 1, the NFV system may include an NFV management and orchestration system (MANO) 128, an NFV infrastructure (NFVI) 130, multiple virtualized network functions (VNF) 108, multiple element management systems (EMS) 122, a Service, VNF and Infrastructure Description system 126, and one or more operation support systems/business support systems (OSS/BSS) 124.
The NFV MANO 128 may include an NFV orchestrator (NFVO) 102, one or more VNF managers (VNFM) 104, and one or more virtualized infrastructure managers (VIM) 106. The NFVI 130 may include a hardware resource layer including computing hardware 112, storage hardware 114, and network hardware 116, a virtualization layer, and a virtual resource layer including virtual computing 110 (such as a virtual machine), virtual storage 118, and a virtual network 120. The computing hardware 112 may be a dedicated processor or a general processor configured to provide processing and computing functions. The storage hardware 114 is configured to provide a storage capability, and the storage capability may be provided by the storage hardware 114 itself (such as a local memory of a server), or may be provided by using a network (for example, a server connects to a network storage device by using a network). The network hardware 116 may be a switch, a router, and/or another network device, the network hardware 116 is configured to implement communication among multiple devices, and the multiple devices are in a wireless or wired connection. The virtualization layer in the NFVI 130 is used to abstract a hardware resource at the hardware resource layer and decouple the VNF 108 from a physical layer to which the hardware resource belongs, to provide the VNF with a virtual resource. As shown in FIG. 1, the virtual resource may include the virtual computing 110, the virtual storage 118, and the virtual network 120. The virtual computing no and the virtual storage 118 may be provided to the VNF 108 in a form of a virtual machine or another virtual container. For example, one or more VNFs 108 may be deployed in a virtual machine. The virtualization layer forms the virtual network 120 by abstracting the network hardware 116. The virtual network 120, such as a virtual switch (Vswitches), is used to implement communication among multiple virtual machines or multiple other types of virtual containers carrying the VNF. Network hardware virtualization may be implemented by using a virtual LAN (VLAN), a virtual private LAN service (VPLS), a virtual extensible local area network (VxLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), or another technology. The OSS/BSS 124 mainly targets a telecom service operator, and provides comprehensive network management and service operation functions including network management (such as fault monitoring and network information collecting), charging management, customer service management, and the like. The VNF and infrastructure description system 126 is described in detail in an ETSI GS NFV 002 v1.1.1 standard, and details are not described in the embodiments of the present invention.
The NFV MANO 128 may be used to implement monitoring and managing of the VNF 108 and the NFVI 130. The NFVO 102 is mainly responsible for NS lifecycle management to implement a network service orchestration function, and for NFVI resource orchestration across multiple VIMs to implement a resource orchestration function. The NFVO may communicate with one or more VNFMs 104, so as to implement a resource-related request, send configuration information to the VNFM 104, and collect status information of the VNF 108. In addition, the NFVO 102 may further communicate with the VIM 106, so as to implement resource allocation and/or reserve and exchange configuration information and status information of the virtualized hardware resource. The VNFM 104 may be configured to manage one or more VNFs 108 and implement various management functions, for example, initializing, updating, querying, and/or terminating the VNF 108. The VIM 106 may be used to control and manage an interaction between the VNF 108 and each of the computing hardware 112, the storage hardware 114, the network hardware 116, the virtual computing 110, the virtual storage 118, and the virtual network 120. For example, the VIM 106 may be configured to perform a resource allocation operation on the VNF 108. The VNFM 104 and the VIM 106 may communicate with each other to exchange the configuration and status information of the virtualized hardware resource.
The NFVI 130 includes hardware and software, and the hardware and software collectively build a virtualization environment to deploy, manage, and implement the VNF 108. In other words, the hardware resource layer and the virtual resource layer are used to provide a virtual resource to the VNF 108, such as a virtual machine or a virtual container in another form.
As shown in FIG. 1, the VNFM 104 may communicate with the VNF 108 and the EMS 122, so as to perform VNF lifecycle management and exchange configuration/status information. The VNF 108 is virtualization of at least one network function, and the network function is previously provided by a physical network device. In an implementation manner, the VNF 108 may be a virtualized mobility management entity (MME) node used to provide all network functions provided by a typical non-virtualized MME device. In another implementation manner, the VNF 108 may be configured to implement functions of some components among all components provided on a non-virtualized MME device. One or more VNFs 108 can be deployed on one virtual machine (or a virtual container in another form). The EMS 122 may be configured to manage one or more VNFs.
NFV policy management refers to management of rules governing different NFV functions (such as a VNF or NS scaling operation, access control, resource management, and fault management). A policy is defined with a condition and a corresponding action. For example, a scaling policy may state to execute a related action (for example, scale down a VNF) if a required condition (for example, relatively low resource usage of the VNF) is met.
The NFVO, the VNFM, and the VIM in the NFV MANO provide a policy management interface to the OSS/BSS, the NFVO, and the NFVO respectively, so as to allow an authorized entity or function block to manage an NFV policy. An interface exposed by the NFVO provides support for managing policies related to an NS instance, a VNF instance, and an NFVI resource (such as authorization/access control and resource reserving/layout/allocation). Interfaces exposed by the VNFM and the VIM provide support for managing policies related to VNF and NFVI resources respectively to meet a requirement of the NFVO. An operation that can be performed on these interfaces includes creating, updating, deleting, querying, activating, and deactivating a policy, and the like.
Using VNF instance scaling as an example, although a scaling operation on a VNF instance is performed by the VNFM, a scaling decision may be made by the OSS/BSS, the EMS, the NFVO, the VNFM, or the VIM based on a given policy. The deciding process of the OSS/BSS, the EMS, the NFVO, the VNFM, or the VIM may be triggered by a monitoring function performed by itself, or may be triggered by an event detection and reporting function of another entity or function block. For example, the VIM may be triggered into a scaling decision process because of factors such as network congestion and a quantity of sessions, the VNFM may be triggered into a scaling decision process because of factors such as VNF resource usage, the NFVO may be triggered into a scaling decision process because of factors such as resource orchestration, the EMS may be triggered into a scaling decision process because of factors such as inter-VNF management, and the OSS/BSS may be triggered into a scaling decision process because of factors such as inter-EMS management, or only because of an operation and maintenance plan. Then, the OSS/BSS, the EMS, the NFVO, the VNFM, or the VIM determines whether a condition defined in the given policy is met, and determines whether to initiate implementation of a defined action. Finally, the scaling decision made by the OSS/BSS, the EMS, the NFVO, the VNFM, or the VIM is sent to the VNFM for execution.
It can be learned from the foregoing that in an NFV system, an execution part may receive to-be-executed decisions sent by multiple parts (including the execution part itself) in the NFV system, and due to lack of a sound decision coordination mechanism, the execution part can only rigidly execute these decisions one by one, which is inflexible.